Listing of Claims 



1. (Previously Presented) A computer-implemented method for the 
intermediation of real time meetings, comprising: 

receiving an indication by a requester system that a requester (R-A) wants to 
request a realtime meeting M-A with a target T-A; 

sending to a decider system (D) a request to conduct a real time meeting M-A; 

queuing the request for the meeting M-A by the decider system; 

receiving by the decider system (D) an availability status of T-A; 

receiving by the decider system (D) an availability status of R-A, where a 
possible availability status includes not available; 

receiving an indication by the requester system that a requester (R-B) wants to 
request a realtime meeting M-B with target T-B, the meeting M-B to be disjoint in time 
with the meeting M-A; and such that one of the parties to M-A (R-A or T-A), known as 
the 'common party' is also the same as one of the parties to M-B (R-B or T-B) and thus 
there are three distinct parties, the decider D being associated with the common party; 

sending to the decider system (D) a request to conduct a real time meeting M-B; 

queuing the request for the meeting M-B by the decider system, such that 
requests for at least two distinct meetings, disjoint in time are placed in the queue, so 
that multiple pending real time meetings for the common party are in the queue at the 
same time; 

receiving by the decider system (D) an availability status of target T-B; 
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receiving by the decider system (D) an availability status of the requester R-B, 
where a possible availability status includes not available; 

initiating, by the decider, one of the two meetings M-A and M-B by connecting the 
common party and the other party to that meeting when the common party and that 
other party are mutually available; and 

dequeuing the request for a meeting. 

2. (Cancelled) 

3. (Previously Presented) The method of claim 1, wherein a system of the target 
T-A is polled to determine the availability of target T-A. 

4. (Previously Presented) The method of claim 1, wherein the system of the 
target T-A pushes the availability status of target T-A to the decider system. 

5. (Previously Presented) The method of claim 1, wherein a system of a party is 
polled to determine the party's availability. 

6. (Previously Presented) The method of claim 1 , wherein the system of a party 
pushes the party's availability status to the decider system. 

7. (Previously Presented) The method of claim 1, wherein mutual availability is 
determined by checking the availability of one of the target/requester pairs T-A/R-A and 
T-B/R-B. 

8. (Previously Presented) The method of claim 1, wherein a request is sent to a 
plurality of targets and mutual availability is determined when the requester and one of 
the plurality of targets is available. 
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9.-53. (Cancelled) 

54. (Previously Presented) The method of claim 1 , further comprising displaying 
the availability status of one of the requesters R-A and R-B on the target system, along 
with an indication that one of the requesters R-A and R-B has requested a meeting. 

55. (Previously Presented) The method of claim 54, wherein the availability 
status is one of in, out, and unknown. 

56. (Previously Presented) The method of claim 1, further comprising displaying 
an availability status of the target T-A on the requester system, along with an indication 
that the requestor has requested a meeting with the target. 

57. (Previously Presented) The method of claim 56, wherein the availability 
status is one of in, out, and unknown. 

58. -71. (Cancelled) 

72. (Previously Presented) The method of claim 1 , wherein the decider system a 
part of the system of the common party for whom it is responsible, and wherein the 
decider already knows the status of the common party for which it is responsible. 

73. (Previously Presented) The method of claim 1 , wherein the decider system 
chooses to activate one of two real time meetings, where the parties for both meetings 
are available, based on at least one of: 

ranking information including manual ranking through a user interface presented 
to the common party; 

priority information provided by either party; 
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the order in time in which the requests were made; and 

relationship information about the parties based on party input or past history. 

74. (Previously Presented) The method of claim 1 , wherein the decider system 
chooses to activate one of two real time meetings, where the parties for both meetings 
are available, based on ranking information including manual ranking through a user 
interface presented to the common party. 

75. (Previously Presented) The method of claim 1 , wherein the decider system 
chooses to activate one of two real time meetings, where the parties for both meetings 
are available, based on priority information provided by either party. 

76. (Previously Presented) The method of claim 1, wherein the decider system 
chooses to activate one of two real time meetings, where the parties for both meetings 
are available, based on the order in time in which the requests were made. 

77. (Previously Presented) The method of claim 1, wherein the decider system 
chooses to activate one of two real time meetings, where the parties for both meetings 
are available, based on relationship information about the parties based on party input 
or past history. 

78. (Previously Presented) The method of claim 1, wherein a non-common 
requester R-A or R-B is party to another, distinct meeting request. 
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79. (Previously Presented) The method of claim 1 , wherein a non-common 
target is party to another distinct meeting request. 

80. (Previously Presented) The method of claim 1 , wherein each of the three 
systems has requested and has pending requests for two or more real-time meetings in 
the queue. 

81 . (Previously Presented) The method of claim 1 , wherein if all parties become 
available at once, only one of the meetings M-A and M-B will occur immediately and the 
other meeting will remain queued. 

82. (Previously Presented) The method of claim 1 , wherein the common party is 
the target T-A and T-B. 

83. (Previously Presented) The method of claim 1, wherein the common party is 
the requestor R-A and R-B and the common party participates in both of the meetings 
M-A and M-B. 

84. (Previously Presented) the method of claim 1 , wherein the target is a specific 
individual selected by the requestor. 

85. (Previously Presented) The method of claim 1, wherein the target is a specific 
individual. 
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86. (Previously Presented) The method of claim 1, wherein the common party is 
the requestor R-A and R-B. 

87. (Previously Presented) The method of claim 1, wherein the target is any one 
of a group of targets. 

88. (Currently Amended) A method comprising: 

transmitting or receiving at a co mputing system a first request for a first real-time 
meeting between a requestor and a first target, the requestor and the first target being 
individuals; 

storing the first request in a queue on the computing s ystem, the queue including 
more than one request for a rea l -time meeting; 

determining that the first target is unavailable using the computing system, mm§ 
the determination being based on a first signal received by the computing system from 
an electronic tool of the first target ^omwtiro-system: 




waiting until the first target changes from being unavailable to being available; 
when the first target is available, determining if the requester is available based 

on a second si gnal received by the computing system ; 

if the requestor is available, then automatically initiating the first real-time 
meeting using computing instructions stored on a computer readable medium of the 
computing system; and 

if the requester is unavailable, then waiting until a time the requestor becomes 
available. 
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89. (Previously Presented) The method of Claim 88, further comprising: 

in response to the requester becoming available, determining if the first target is 
still available; 

if the first target is still available, then initiating the first real-time meeting; and 
if the first target is unavailable, then waiting until the first target becomes 
available. 

90. (Currently Amended) The method of claim 88, further comprising: 
transmitting or receiving a second request for a second real-time meeting 

between the first requester and a second target, the second request being transmitted 
or received between a time the first request is transmitted or received and a time the 
first real-time meeting is initiated; 

storing the second request in the queue; and 

initiating the second real-time meeting prior to the first real-time meeting if the 
second target becomes available before the first target. 

91 . (Currently Amended) The method of claim 88, further comprising; 
transmitting or receiving a second request for a second real-time meeting 

between a second requestor and the first target, the second request being transmitted 
or received between a time the first request is transmitted or received and a time the 
first real-time meeting is initiated; 

storing the second request in the queue; and 

initiating the second real-time meeting prior to the first real-time meeting if the 
second requester becomes available before the first requester. 
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92. (Previously Presented) The method of Claim 78, wherein the non-common 
requester R-A or R-B that is party to another distinct meeting request is a target in that 
meeting request. 

93. (Previously Presented) The method of Claim 1 , wherein the requestor R-A 
changes states from not available to available, while waiting for the realtime meeting M- 
A. 

94. (Previously Presented) The method of Claim 1 , wherein the requestor R-A 
participates in another distinct realtime meeting while waiting for the realtime meeting 
M-A. 

95. (Previously Presented) The method of Claim 1 , wherein the requester R-A 
becomes available when the requestor R-A terminates a call. 

96. (Previously Presented) The method of Claim 1, wherein the requester R-A 
and target T-A are both available when they are both off of the phone. 

97. (Currently Amended) A method comprising: 

transmitting or receiving at a computing system a first request for a first real-time 
meeting between a requestor and a first target, the requestor and the first target being 
individuals; 
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determining that the first target is unavailable, using a the computing system , the 

Mefmjnat ion being based on a first electronic sig nal received from the first target : 

Storing the first request in a queue o n. the comp uting system, the queue including 

more than one request for a reaM|mejTteette 

waiting until the first target changes from being unavailable to being available; 

when the first target is available, automatically determining if the requester is 
available based on a second electronic signal received by the computing system; and 

if the requester is unavailable, then waiting until a time the requestor becomes 
available. 

98. (Previously Presented) The method of Claim 88, further comprising: 

in response to the requester becoming available, determining if the first target is 

still available using computing instructions stored on a computer readable medium of 

the computing system; and 

if the first target is unavailable, then waiting until the first target becomes 

available. 
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